JavaScripti WeakRef mustrid: Mälu-efektiivne objektide haldamine

Kõrgetasemeliste programmeerimiskeelte, nagu JavaScript, maailmas on arendajad sageli kaitstud käsitsi mäluhalduse keerukuse eest. Me loome objekte ja kui neid enam vaja pole, sekkub taustaprotsess, mida tuntakse prügikoristajana (GC), et mälu tagasi võtta. See automaatne süsteem töötab enamasti suurepäraselt, kuid see pole lollikindel. Suurim väljakutse? Soovimatud tugevad viited, mis hoiavad objekte mälus kaua pärast seda, kui need oleks pidanud olema kõrvaldatud, viies peente ja raskesti diagnoositavate mäluleketeni.

Aastaid oli JavaScripti arendajatel selle protsessiga suhtlemiseks piiratud tööriistad. WeakMap ja WeakSet sisseviimine pakkus võimaluse seostada andmeid objektidega, takistamata nende kogumist. Kuid keerukamate stsenaariumide jaoks oli vaja peenemat tööriista. Siia astuvad WeakRef ja FinalizationRegistry – kaks võimsat funktsiooni, mis tutvustati ECMAScript 2021-s ja annavad arendajatele uue taseme kontrolli objektide elutsükli ja mäluhalduse üle.

See põhjalik juhend viib teid nende funktsioonide süvauurimisse. Uurime tugevate ja nõrkade viidete põhimõisteid, lahti harutame WeakRef ja FinalizationRegistry mehhanisme ning mis kõige tähtsam, vaatame läbi praktilisi, reaalseid mustreid, kus neid saab kasutada vastupidavamate, mäluefektiivsemate ja jõudlusele orienteeritumate rakenduste loomiseks.

Põhiprobleemi mõistmine: Tugevad vs. Nõrgad viited

Enne kui saame hinnata WeakRef-i, peame esmalt omama kindlat arusaama, kuidas JavaScripti mäluhaldus põhiliselt töötab. Prügikoristus (GC) töötab põhimõttel, mida nimetatakse ligipääsetavuseks.

Tugevad viited: Vaikimisi ühendus

Viide on lihtsalt viis, kuidas teie koodi üks osa saab objektile ligi pääseda. Vaikimisi on kõik JavaScripti viited tugevad. Tugev viide ühelt objektilt teisele takistab viidatud objekti prügikoristamist seni, kuni viitav objekt on ise ligipääsetav.

Kaaluge seda lihtsat näidet:

            // 'root' on globaalselt ligipääsetavate objektide hulk, näiteks 'window' objekt.
// Loome objekti.
let largeObject = { 
  id: 1,
  data: new Array(1000000).fill('some data') // Suur andmemaht
};

// Loome sellele tugeva viite.
let myReference = largeObject;

// Nüüd, isegi kui me 'unustame' algse muutuja...
largeObject = null;

// ...objekt EI OLE prügikoristuseks kõlblik, sest 'myReference'
// viitab sellele endiselt tugevalt. See on ligipääsetav.

// Ainult siis, kui kõik tugevad viited on kadunud, see kogutakse.
myReference = null;
// Nüüd on objekt ligipääsmatu ja saab GC poolt kogutud.
            

              
                Copy
              
            
          

See on mälulekete alus. Kui pikaealine objekt (nagu globaalne vahemälu või teenuse singleton) hoiab tugevat viidet lühiealisele objektile (nagu ajutine kasutajaliidese element), siis seda lühiealist objekti ei koguta kunagi, isegi pärast seda, kui seda enam vaja pole.

Nõrgad viited: Õrn seos

Nõrk viide, vastupidi, on viide objektile, mis ei takista objekti prügikoristamist. See on nagu märkme omamine, millele on kirjutatud objekti aadress. Saate märkme abil objekti leida, kuid kui objekt lammutatakse (prügikoristatakse), ei takista aadressiga märge seda. Märge muutub lihtsalt kasutuks.

See on täpselt see funktsionaalsus, mida WeakRef pakub. See võimaldab teil hoida viidet sihtobjektile, sundimata seda mälus püsima. Kui prügikoristaja käivitub ja määrab, et objekt ei ole enam tugevate viidetega ligipääsetav, siis see kogutakse ja nõrk viide osutab seejärel tühjusele.

Põhimõisted: Süvaanalüüs WeakRef-ist ja FinalizationRegistry-st

Lähme lahti kahte peamist API-t, mis võimaldavad neid täiustatud mäluhalduse mustreid.

WeakRef API

WeakRef objekti on lihtne luua ja kasutada.

Süntaks:

            const targetObject = { name: 'Minu Sihtobjekt' };
const weakRef = new WeakRef(targetObject);

            

              
                Copy
              
            
          

WeakRef-i kasutamise võti on selle meetod deref(). See meetod tagastab ühe kahest asjast:

• Aluseks olev sihtobjekt, kui see mälus veel eksisteerib.
• undefined, kui sihtobjekt on prügikoristatud.

            let userProfile = { userId: 123, theme: 'dark' };
const userProfileRef = new WeakRef(userProfile);

// Objekti ligipääsuks peame selle de-viitama (dereference).
let retrievedProfile = userProfileRef.deref();

if (retrievedProfile) {
  console.log(`Kasutajal ${retrievedProfile.userId} on ${retrievedProfile.theme} teema.`);
} else {
  console.log('Kasutajaprofiil on prügikoristatud.');
}

// Nüüd eemaldame objekti ainsa tugeva viite.
userProfile = null;

// Mingil hetkel tulevikus võib GC käivituda. Me ei saa seda sundida.
// Pärast GC-d annab deref() kutsumine undefined.
setTimeout(() => {
  let finalCheck = userProfileRef.deref();
  console.log('Lõplik kontroll:', finalCheck); // Tõenäoliselt 'undefined'
}, 5000);

            

              
                Copy
              
            
          

Kriitiline hoiatus: Levinud viga on salvestada deref() tulemus muutujasse pikemaks ajaks. See loob objektile uue tugeva viite, pikendades potentsiaalselt selle eluiga ja nurjates WeakRef-i kasutamise esialgse eesmärgi.

            // Antipatroon: Ärge tehke seda!
const myObjectRef = weakRef.deref(); 

// Kui myObjectRef ei ole null, on see nüüd tugev viide.
// Objekti ei koguta seni, kuni myObjectRef eksisteerib.

// Korrektne patroon:
function operateOnObject(weakRef) {
  const target = weakRef.deref();
  if (target) {
    // Kasutage 'target' ainult selles skoobis.
    target.doSomething();
  }
}

            

              
                Copy
              
            
          

FinalizationRegistry API

Mis siis, kui peate teadma, millal objekt on kogutud? Lihtsalt kontrollimine, kas deref() tagastab undefined, nõuab pidevat päringute tegemist, mis on ebaefektiivne. Siin tuleb mängu FinalizationRegistry. See võimaldab teil registreerida tagasikutsefunktsiooni, mis käivitatakse pärast sihtobjekti prügikoristamist.

Kujutage seda kui surmajärgset koristusmeeskonda. Te ütlete sellele: "Jälgi seda objekti. Kui see on kadunud, käivita see puhastustoiming minu eest."

Süntaks:

            // 1. Loo register puhastuse tagasikutsega.
const registry = new FinalizationRegistry(heldValue => {
  // See tagasikutse käivitatakse pärast sihtobjekti kogumist.
  console.log(`Objekt on kogutud. Puhastuse väärtus: ${heldValue}`);
});

// 2. Loo objekt ja registreeri see.
(() => {
  let anObject = { id: 'resource-456' };

  // Registreeri objekt. Anname edasi 'heldValue', mis antakse
  // meie tagasikutsele. See väärtus EI TOHI olla viide objektile endale!
  registry.register(anObject, 'resource-456-cleaned-up');

  // Tugev viide objektile anObject kaob, kui see IIFE lõpeb.
})();

// Mingil hetkel hiljem, pärast GC käivitamist, käivitub tagasikutse ja näete:
// "Objekt on kogutud. Puhastuse väärtus: resource-456-cleaned-up"

            

              
                Copy
              
            
          

Meetod register võtab vastu kolm argumenti:

1. target: Objekt, mida jälgitakse prügikoristuse suhtes. See peab olema objekt.
2. heldValue: Väärtus, mis antakse edasi teie puhastuse tagasikutsele. See võib olla mis tahes (string, number jne), kuid see ei tohi olla sihtobjekt ise, kuna see looks tugeva viite ja takistaks kogumist.
3. unregisterToken (valikuline): Objekt, mida saab kasutada sihtobjekti käsitsi registreerimise tühistamiseks, takistades tagasikutse käivitumist. See on kasulik, kui teostate selgesõnalise puhastuse ja te ei vaja enam finalizeri käivitumist.

            const unregisterToken = { id: 'minu-tunnus' };
registry.register(anObject, 'mingi-väärtus', unregisterToken);

// Hiljem, kui teeme selgesõnalise puhastuse...
registry.unregister(unregisterToken);
// Nüüd ei käivitu finaliseerimise tagasikutse 'anObject'-i jaoks.

            

              
                Copy
              
            
          

Olulised hoiatused ja lahtiütlused

Enne mustrite juurde asumist peate te selle API kohta need kriitilised punktid omaks võtma:

• Mittemääravus: Teil puudub kontroll selle üle, millal prügikoristaja töötab. FinalizationRegistry puhastuse tagasikutse võidakse käivitada kohe, pika viivituse järel või potentsiaalselt üldse mitte (nt kui programm lõpeb).
• Mitte destruktor: See ei ole C++-stiilis destruktor. Ärge tuginege sellele kriitiliste olekute salvestamise või ressursside haldamise puhul, mis peavad toimuma õigeaegselt või garanteeritult.
• Implementatsioonist sõltuv: Prügikoristuse ja finaliseerimise tagasikutsete täpne ajastus ja käitumine võivad JavaScripti mootorite (V8 Chrome'is/Node.js-is, SpiderMonkey Firefoxis jne) vahel erineda.

Rusikareegel: Pakkuge alati selgesõnaline puhastusmeetod (nt .close(), .dispose()). Kasutage FinalizationRegistry-t teisejärgulise turvavõrguna, et püüda kinni juhtumid, kus selgesõnaline puhastus jäi tegemata, mitte peamise mehhanismina.

Praktilised mustrid `WeakRef`-i ja `FinalizationRegistry` jaoks

Nüüd põneva osa juurde. Vaatame mitmeid praktilisi mustreid, kus need täiustatud funktsioonid saavad lahendada reaalseid probleeme.

Muster 1: Mälutundlik vahemällu salvestamine

Probleem: Peate juurutama vahemälu suurte, arvutuslikult kallite objektide jaoks (nt parsetud andmed, pildiblobid, renderdatud diagrammiandmed). Kuid te ei taha, et vahemälu oleks ainus põhjus, miks need suured objektid mälus hoitakse. Kui miski muu rakenduses vahemällu salvestatud objekti ei kasuta, peaks see automaatselt vahemälust eemaldamisele kuuluma.

Lahendus: Kasutage Map-i või tavalist objekti, kus väärtusteks on WeakRef-id suurtele objektidele.

            class WeakRefCache {
  constructor() {
    this.cache = new Map();
  }

  set(key, largeObject) {
    // Salvesta objektile WeakRef, mitte objekt ise.
    this.cache.set(key, new WeakRef(largeObject));
    console.log(`Vahemällu salvestatud objekt võtmega: ${key}`);
  }

  get(key) {
    const ref = this.cache.get(key);
    if (!ref) {
      return undefined; // Pole vahemälus
    }

    const cachedObject = ref.deref();
    if (cachedObject) {
      console.log(`Vahemälu tabamus võtmele: ${key}`);
      return cachedObject;
    } else {
      // Objekt on prügikoristatud.
      console.log(`Vahemälu möödalask võtmele: ${key}. Objekt koguti.`);
      this.cache.delete(key); // Puhasta aegunud kirje.
      return undefined;
    }
  }
}

const cache = new WeakRefCache();

function processLargeData() {
  let largeData = { payload: new Array(2000000).fill('x') };
  cache.set('myData', largeData);
  
  // Kui see funktsioon lõpeb, on 'largeData' ainus tugev viide,
  // kuid see on kohe skoobist väljumas.
  // Vahemälu hoiab ainult nõrka viidet.
}

processLargeData();

// Kontrolli vahemälu kohe
let fromCache = cache.get('myData');
console.log('Saadud vahemälust kohe:', fromCache ? 'Jah' : 'Ei'); // Jah

// Pärast viivitust, lubades potentsiaalset GC-d
setTimeout(() => {
  let fromCacheLater = cache.get('myData');
  console.log('Saadud vahemälust hiljem:', fromCacheLater ? 'Jah' : 'Ei'); // Tõenäoliselt Ei
}, 5000);

            

              
                Copy
              
            
          

See muster on uskumatult kasulik kliendipoolsete rakenduste jaoks, kus mälu on piiratud ressurss, või serveripoolsete rakenduste jaoks Node.js-is, mis käsitlevad paljusid samaaegseid päringuid suurte, ajutiste andmestruktuuridega.

Muster 2: Kasutajaliidese elementide ja andmesiduse haldamine

Probleem: Keerulises ühe lehe rakenduses (SPA) võib teil olla keskne andmehoidla või teenus, mis peab teavitama erinevaid kasutajaliidese komponente muudatustest. Levinud lähenemine on vaatlejapatroon, kus kasutajaliidese komponendid tellivad andmehoidlast. Kui salvestate andmehoidlasse otsesed, tugevad viited nendele kasutajaliidese komponentidele (või nende tugiobjektidele/kontrolleritele), loote tsüklilise viite. Kui komponent eemaldatakse DOM-ist, takistab andmehoidla viide selle prügikoristust, põhjustades mälulekke.

Lahendus: Andmehoidla hoiab massiivi oma tellijate WeakRef-idest.

            class DataBroadcaster {
  constructor() {
    this.subscribers = [];
  }

  subscribe(component) {
    // Salvesta nõrk viide komponendile.
    this.subscribers.push(new WeakRef(component));
  }

  notify(data) {
    // Teavitades peame olema kaitsvad.
    const liveSubscribers = [];
    for (const ref of this.subscribers) {
      const subscriber = ref.deref();
      if (subscriber) {
        // See on veel elus, seega teavita seda.
        subscriber.update(data);
        liveSubscribers.push(ref); // Hoia seda järgmiseks ringiks
      } else {
        // See koguti, ära hoia selle WeakRef-i.
        console.log('Tellija komponent prügikoristati.');
      }
    }
    // Puhasta surnud viidete loend.
    this.subscribers = liveSubscribers;
  }
}

// Mock kasutajaliidese komponendi klass
class MyComponent {
  constructor(id) {
    this.id = id;
  }
  update(data) {
    console.log(`Komponent ${this.id} sai värskenduse:`, data);
  }
}

const broadcaster = new DataBroadcaster();

let componentA = new MyComponent(1);
broadcaster.subscribe(componentA);

function createAndDestroyComponent() {
  let componentB = new MyComponent(2);
  broadcaster.subscribe(componentB);
  // componentB tugev viide kaob, kui see funktsioon tagastab.
}

createAndDestroyComponent();

broadcaster.notify({ message: 'Esimene värskendus' });
// Oodatav väljund:
// Komponent 1 sai värskenduse: { message: 'Esimene värskendus' }
// Komponent 2 sai värskenduse: { message: 'Esimene värskendus' }

// Pärast viivitust, et lubada GC-d
setTimeout(() => {
  console.log('\n--- Teavitamine pärast viivitust ---');
  broadcaster.notify({ message: 'Teine värskendus' });
  // Oodatav väljund:
  // Tellija komponent prügikoristati.
  // Komponent 1 sai värskenduse: { message: 'Teine värskendus' }
}, 5000);

            

              
                Copy
              
            
          

See muster tagab, et teie rakenduse olekuhalduse kiht ei hoia juhuslikult kogu kasutajaliidese komponentide puid elus pärast seda, kui need on eemaldatud ja kasutajale enam nähtavad ei ole.

Muster 3: Haldamata ressursside puhastus

Probleem: Teie JavaScripti kood suhtleb ressurssidega, mida JS-i prügikoristaja ei halda. See on tavaline Node.js-is natiivsete C++ lisamoodulite kasutamisel või brauseris WebAssembly (Wasm) abil töötamisel. Näiteks võib JS-i objekt esindada failikäsitlejat, andmebaasiühendust või keerulist andmestruktuuri, mis on eraldatud Wasm-i lineaarses mälus. Kui JS-i kapseldav objekt prügikoristatakse, lekib aluseks olev natiivne ressurss, välja arvatud juhul, kui see on selgesõnaliselt vabastatud.

Lahendus: Kasutage FinalizationRegistry-t turvavõrguna välise ressursi puhastamiseks, kui arendaja unustab kutsuda selgesõnalise meetodi close() või dispose().

            // Simuleerime natiivset sidumist.
const native_bindings = {
  open_file(path) {
    const handleId = Math.random();
    console.log(`[Natiivne] Fail '${path}' avati käepidemega ${handleId}`);
    return handleId;
  },
  close_file(handleId) {
    console.log(`[Natiivne] Fail käepidemega ${handleId} suleti. Ressurss vabastatud.`);
  }
};

const fileRegistry = new FinalizationRegistry(handleId => {
  console.log('Finalizer käivitub: faili käepidet ei suletud selgesõnaliselt!');
  native_bindings.close_file(handleId);
});

class ManagedFile {
  constructor(path) {
    this.handle = native_bindings.open_file(path);
    // Registreeri see eksemplar registrisse.
    // 'heldValue' on käepide, mida on vaja puhastamiseks.
    fileRegistry.register(this, this.handle);
  }

  // Vastutustundlik viis puhastamiseks.
  close() {
    if (this.handle) {
      native_bindings.close_file(this.handle);
      // TÄHTIS: Ideaalis peaksime registreeringu tühistama, et finalizer ei käivituks.
      // Lihtsuse huvides jätab see näide unregisterTokeni välja, kuid reaalses rakenduses kasutaksite seda.
      this.handle = null;
      console.log('Fail suleti selgesõnaliselt.');
    }
  }
}

function processFile() {
  const file = new ManagedFile('/path/to/my/data.bin');
  // ... tee failiga tööd ...
  // Arendaja unustab kutsuda file.close()
}

processFile();

// Sel hetkel on 'file' objekt ligipääsmatu.
// Mingil hetkel hiljem, pärast GC käivitumist, käivitub FinalizationRegistry tagasikutse.
// Väljund sisaldab lõpuks:
// "Finalizer käivitub: faili käepidet ei suletud selgesõnaliselt!"
// "[Natiivne] Fail käepidemega ... Ressurss vabastatud."

            

              
                Copy
              
            
          

Muster 4: Objekti metaandmed ja "kõrvaltabelid"

Probleem: Peate seostama metaandmeid objektiga, muutmata objekti ennast (võib-olla on see külmutatud objekt või kolmanda osapoole teegist). WeakMap sobib selleks suurepäraselt, kuna see võimaldab võtmeobjekti koguda. Aga mis siis, kui peate silumiseks või jälgimiseks jälgima objektide kogumit ja soovite teada, millal need kogutakse?

Lahendus: Kasutage elusate objektide jälgimiseks Set-i WeakRef-idest ja FinalizationRegistry-t, et nende kogumisest teada saada.

            class ObjectLifecycleTracker {
  constructor(name) {
    this.name = name;
    this.liveObjects = new Set();
    this.registry = new FinalizationRegistry(objectId => {
      console.log(`[${this.name}] Objekt id-ga '${objectId}' on kogutud.`);
      // Siin saaksite värskendada mõõdikuid või sisemist olekut.
    });
  }

  track(obj, id) {
    console.log(`[${this.name}] Alustati objekti jälgimist id-ga '${id}'`);
    const ref = new WeakRef(obj);
    this.liveObjects.add(ref);
    this.registry.register(obj, id);
  }

  getLiveObjectCount() {
    // See on reaalse rakenduse jaoks veidi ebaefektiivne, kuid demonstreerib põhimõtet.
    let count = 0;
    for (const ref of this.liveObjects) {
      if (ref.deref()) {
        count++;
      } else {
        // Valikuliselt eemaldage surnud viited hulgast efektiivsuse tagamiseks
        // this.liveObjects.delete(ref);
      }
    }
    return count;
  }
}

const widgetTracker = new ObjectLifecycleTracker('VidinaJälgija');

function createWidgets() {
  let widget1 = { name: 'Peamine vidin' };
  let widget2 = { name: 'Ajutine vidin' };
  widgetTracker.track(widget1, 'widget-1');
  widgetTracker.track(widget2, 'widget-2');

  // Tagasta tugev viide ainult ühele vidinale
  return widget1;
}

const mainWidget = createWidgets();

console.log(`Elusad objektid kohe pärast loomist: ${widgetTracker.getLiveObjectCount()}`);

// Pärast viivitust peaks widget2 olema kogutud.
setTimeout(() => {
  console.log('\n--- Pärast viivitust ---');
  console.log(`Elusad objektid pärast GC-d: ${widgetTracker.getLiveObjectCount()}`);
}, 5000);

// Oodatav väljund:
// [VidinaJälgija] Alustati objekti jälgimist id-ga 'widget-1'
// [VidinaJälgija] Alustati objekti jälgimist id-ga 'widget-2'
// Elusad objektid kohe pärast loomist: 2
// --- Pärast viivitust ---
// [VidinaJälgija] Objekt id-ga 'widget-2' on kogutud.
// Elusad objektid pärast GC-d: 1

            

              
                Copy
              
            
          

Millal *mitte* kasutada `WeakRef`-i

Suure võimuga kaasneb suur vastutus. Need on teravad tööriistad ja nende vale kasutamine võib muuta koodi analüüsimise ja silumise raskemaks. Siin on stsenaariumid, kus peaksite peatuma ja uuesti kaaluma.

• Kui piisab `WeakMap`-ist: Kõige tavalisem kasutusjuhtum on андмете seostamine objektiga. WeakMap on täpselt selleks loodud. Selle API on lihtsam ja vähem veaohtlik. Kasutage WeakRef-i siis, kui vajate nõrka viidet, mis ei ole võtmeks võtme-väärtuse paaris, näiteks väärtusena Map-is või elemendina loendis.
• Garanteeritud puhastuseks: Nagu varem öeldud, ärge kunagi tuginege FinalizationRegistry-le kui ainsale mehhanismile kriitiliseks puhastuseks. Mittemäärav iseloom muudab selle sobimatuks lukkude vabastamiseks, tehingute sooritamiseks või mis tahes toiminguks, mis peab toimuma usaldusväärselt. Pakkuge alati selgesõnaline meetod.
• Kui teie loogika nõuab objekti olemasolu: Kui teie rakenduse korrektsus sõltub objekti kättesaadavusest, peate sellele hoidma tugevat viidet. WeakRef-i kasutamine ja seejärel üllatumine, kui deref() tagastab undefined, on märk valest arhitektuurilisest disainist.

Jõudlus ja käitusaegne tugi

WeakRef-ide loomine ja objektide registreerimine FinalizationRegistry-sse ei ole tasuta. Nende toimingutega kaasneb väike jõudluse lisakulu, kuna JavaScripti mootor peab tegema lisaraamatupidamist. Enamikus rakendustes on see lisakulu tühine. Kuid jõudluskriitilistes tsüklites, kus võite luua miljoneid lühiealisi objekte, peaksite tegema jõudlusanalüüsi, et veenduda, et olulist mõju ei ole.

2023. aasta lõpu seisuga on tugi igati suurepärane:

• Google Chrome: Toetatud alates versioonist 84.
• Mozilla Firefox: Toetatud alates versioonist 79.
• Safari: Toetatud alates versioonist 14.1.
• Node.js: Toetatud alates versioonist 14.6.0.

See tähendab, et saate neid funktsioone julgelt kasutada igas kaasaegses veebi- või serveripoolses JavaScripti keskkonnas.

Kokkuvõte

WeakRef ja FinalizationRegistry ei ole tööriistad, mille järele iga päev haarate. Need on spetsialiseeritud instrumendid konkreetsete, keeruliste mäluhaldusega seotud probleemide lahendamiseks. Need esindavad JavaScripti keele küpsemist, andes ekspertaarendajatele võimaluse luua kõrgelt optimeeritud, ressursiteadlikke rakendusi, mida varem oli ilma leketeta raske või võimatu luua.

Mõistes mälutundliku vahemällu salvestamise, lahutatud kasutajaliidese haldamise ja haldamata ressursside puhastamise mustreid, saate need võimsad API-d oma arsenali lisada. Pidage meeles kuldreeglit: kasutage neid ettevaatusega, mõistke nende mittemääratud olemust ja eelistage alati lihtsamaid lahendusi, nagu õige ulatus ja WeakMap, kui need probleemiga sobivad. Õigesti kasutades võivad need funktsioonid olla võtmeks uue jõudluse ja stabiilsuse taseme avamiseks teie keerukates JavaScripti rakendustes.